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Abstract. Communication platforms for ubiquitous computing need to 
be flexible, self-organizing, highly scalable and energy efficient, because in 
the envisioned scenarios a large number of autonomous entities communi- 
cate in potentially unpredictable ways. Short-range wireless technologies 
form the basis of such communication platforms. In this paper we inves- 
tigate device discovery in Bluetooth, a candidate wireless technology for 
ubiquitous computing. Detecting new devices accounts for a significant 
portion of the total energy consumption in Bluetooth. It is argued that 
the standard Bluetooth rendezvous protocols for device detection are not 
well suited for ubiquitous computing scenarios, because they do not scale 
to a large number of devices, take too long to complete, and consume too 
much energy. Based on theoretical considerations, practical experiments 
and simulation results, recommendations for choosing inquiry parameters 
are given that optimize discovery performance. We propose an adaptive 
rendezvous protocol that significantly increases the performance of the 
inquiry procedure by implementing cooperative device discovery. Also 
higher level methods to optimize discovery performance, specifically the 
use of sensory data and context information, are considered. 



1 Introduction 

Ubiquitous computing [10,11] envisions that information technology is present 
throughout the physical environment, integrated in a broad range of everyday 
objects. Thereby, information technology becomes omnipresent but at the same 
time also invisible to users. Everyday items are augmented with self- awareness 
and awareness of their surroundings in order to provide new functionality and 
novel interaction patterns. 

A first step towards this vision is to attach smaU computing devices to ev- 
eryday objects. Smart things sense their surroundings and cooperate with one 
another. Information processing takes place autonomously in the background, 
unsupervised by human beings. To collect information about their surroundings, 

* Part of this work was conducted in the Smart-Its project, which is funded by the 
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smart artifacts need to be equipped with sensors for various physical parame- 
ters. To cooperate with other entities, e.g. to distribute collected sensor data 
or to use services offered by other entities, smart artifacts need to be able to 
communicate. 

The communication of smart objects poses several challenging problems: the 
communication technology must be unobtrusive; the scarce radio resources must 
be used effectively in order to achieve scalability; communication must hap- 
pen without mediation, spontaneously and without administration; previously 
unknown devices have to be discovered automatically; a wide range of commu- 
nication patterns and traffic volumes must be accommodated for; and the least 
energy possible must be used. 

In the Smart-Its project [17] small computing devices - so-called Smart- 
Its - were developed that are attached to everyday items providing them with 
collective awareness and supporting intelligent collaborative behavior. As a com- 
munication platform we investigate low-power fixed-frequency modules as well 
as Bluetooth [5], which is a frequency-hopping system. Fig. 1 shows a Smart- It 
equipped with a Bluetooth module and an attached sensor board [13]. 




Fig. 1. A Bluetooth-enabled Smart-Its prototype 



One reason lor using Hluetooth ni the Smart-Its project is that frequency- 
hoppmg as a sfirc^ad-spi-ci rum technique offers higher robustness and scalability 
than fixed-lr(^(]uon( \ snsI.olhs. Smart-Its are designed to operate in areas with 
dozens of devices m ranee and are going to be equipped not only with standard 
sensors for temperature and acceleration but also with more data intensive sen- 
sors such as low resolution cameras. Hence, scalabilitv m terms of number of 
devices m communication range and volume oi data traffic is crucial. 

The issue we focus on m this paper is the discoverv ol new devices, which 
is a necessarv task for each device in an ad hoc network. Device detection is 
an essential part of the rendezvous laver. The challenge is to find all potential 
communication partners present m communication range using the shortest time 
and the least amount ot energy possible. This issue is critical if a huge number 
of devices are present as in the scenarios envisioned. Although Bluetooth seems 
to be a promising technology for ubiquitous computing, the insufficient scalabil- 



ity and high energy consumption of its rendezvous layer limit its applicability. 
While investigating Bluetooth, we found that the Bluetooth modes for device 
detection - Inquiry and Inquiry Scan - consume significantly more energy 
than normal receive and transmit modes. For the modules used in the Smart-Its 
project, energy consumption in INQUIRY mode is approximately twice as high as 
in transmit mode [12, 14]. Therefore, our goal in this paper is to reduce the en- 
ergy consumption of Bluetooth's rendezvous layer during device discovery, while 
at the same time increasing its scalability. This is achieved through appropriate 
settings for the inquiry parameters, an adaptive protocol for cooperative device 
discovery, and the utilization of context information. 

Due to a limited number of available Bluetooth modules and their restricted 
functionality, the performance evaluation of Bluetooth's rendezvous layer and of 
the proposed adaptions are based on simulation results with the Network Simu- 
lator (ns-2) [15] and BlueHoc [16], an open-source Bluetooth simulator provided 
by IBM. Considerable extensions of BlueHoc were necessary to carry out the 
simulation experiments described in this paper. 

The remainder of the paper is structured as follows: Section 2 motivates 
the need for a rendezvous layer in ad- hoc networks in general. Section -3 intro- 
duces the Bluetooth inquiry procedure in particular, while section 4 evaluates its 
performance in terms of time to complete, energy consumption, and scalability. 
Section 5 discusses how to set the Bluetooth inquiry parameters in order to opti- 
mize performance. In section 6 we present an adaptive rendezvous layer protocol 
that optimizes discovery performance in settings with many devices present. In 
section 7 several possibilities for the utilization of context information in device 
discovery are explored. We conclude with a general judgement of the Bluetooth 
discovery process and give some suggestions for improvements. 

2 The Rendezvous Layer 

In mobile ad lux- on\ imniiKnits ot smart devices, units mitiallv posses no in- 
formation aboiil noarln dtn'ices. and no centrahzed instance exists where de- 
vices can ac(|iJir(^ inloriiial.ion about their environment. Thereiore. protocols are 
needed that pi()\i(|( (ii(i„\ (friddit iiu uis I. i .1 t .tiii-^iuw de\ Kes and enable 
peer tommuiiK atioiis in luobilf f ii\ uoiuui lit-. Ih iuuk/\ous la^el contains 
such protocols. A rendezvous la^'er ior hxed-irequencv svstems introduced m [4] 
provides a mechanism tor node discovert' using a beaconing approach and imple- 
ments power saving meachnisms that allow units to be put m sleep modes be- 
tween communication periods. Our approach to the rendezvous laver is different 
in that we concentrate on Bluetooth s device discoverv and trv to minimize power 
consumption by minimizing the time units have to stay m power-consuming de- 
vice detection modes. Scheduled rendezvous are not an issue of this paper. 

The rendezvous layer enables deA'ices to communicate with each other by 
helping them to find potential communication partners. The actual data traffic 
after connection establishment, however, does not flow through the rendezvous 
layer. The term "layer" might therefore be misleading, but it emphasizes that 



■Vr(i|ii!!>i 



'tsysical Isyfif \\ beaconing 



Fig. 2. Communication platform architecture for smart devices 



the results of rendezvous layer protocols are a precondition for communication 
and that every mobile node generally needs to use rendezvous protocols to be 
able to connect to other devices. 

Fig. 2 shows a possible communication platform architecture for smart de- 
vices. The actual position of the rendezvous layer strongly depends on the con- 
crete design. It is possible that it reaches down to the hardware layer, e.g. when 
low-power RF detection circuits are used to detect other devices. For fixed- 
frequency systems, [4] distinguishes between client and server beaconing. In 
the envisioned ubiquitous computing application scenarios there are no fixed 
client/server roles. Hence, it seems advantageous to distinguish between dynam- 
ically assigned roles such as service provider and service consumer. In general 
each device acts both as service provider and service consumer. 

The rendezvous layer for frequency hopping systems is more complicated 
than for fixed-frequency solutions. This is mainly due to an initial frequency 
discrepancy between devices. Frequency hopping systems also result in a much 
higher energy consumption of the rendezvous layer compared to fixed-frequency 
systems. In Bluetooth, the rendezvous layer mainly consists of the Inquiry and 
Inquiry Scan procedures. 

3 Bluetooth's Inquiry Procedure 

The Bluetooth standard introduces an INQUIRY procedure for device detection 
and a PAGE procedure tor connection estabhshment. Both are asymmetric pro- 
cesses initiated bv the unit that wants to collect device information or create a 
connection. The initial in-i iinii spc^nds signihcantlv more enere;v than the unit 
that is inquired or pa<iV'(l. liocaiis.^ it stavs m Inquiry or Page mode for a long 
time whereas the othei Ipm e iii is i s -innmg mode onh peiiodically for short 
time intervals. The PAGE and iNyl IRY procedures resemble each other in that 
they both have to overcome an initial trequency discrepancy between devices. 
However, a paging unit already has an estimate ol the scanning unit's current 
clock which it acquired during a preceding inquiry. 



During the inquiry process, the unit that wants to find devices in communica- 
tion range periodically enters the Inquiry state. Devices that want to advertise 
their presence and thereby agree to be found by other devices enter the In- 
quiry Scan state regularly. Typically, in the envisioned application scenarios 
devices enter both states, Inquiry and Inquiry Scan, in certain time inter- 
vals. But in order to ensure that two devices find each other, one has to be 
in Inquiry and the other in Inquiry Scan state simultaneously. To prevent 
devices from synchronizing their inquiry states, the time between the start of 
two consecutive inquiries, Tinquiry, has to be randomly distributed in an interval 
Kg«ir-a' Tr^quiryl- Fig- 3 and Tab. 1 show the parameters influencing Bluetooth's 
inquiry procedure. 
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Fig. 3. Important inquiry parameters 



The device in Inquiry state broadcasts ID packets on different frequencies 
at twice the usual hopping rate. That is, it sends two ID packets in a 625 
wide slot, and afterwards listens for 625^s for responses from other devices. 
This is repeated for the duration of the entire inquiry window, T„ inquiry . which 
is typically in the range of several seconds. There exists a unique inquiry hop- 
ping sequence comprising 32 frequencies^ on which an inquirer sends out ID 
packets. This sequence is the same for all devices, only the phase within the 
sequence is determined by the native clock CLKN of the inquiring unit and 
therefore specific for each device. Furthermore, for each 1.28 the inquiry hop- 
ping sequence is divided into two disjunct, consecutive trains .4 and B, each 
containing 16 frequencies. The inquirer needs Ttrain = 10 ms to both send on all 
frequencies in a single train and check for potential responses. According to the 
Bluetooth specification [5], the frequencies in "a single train must be repeated 
for at least Ninquiry = 256 times before a new train is used" . The phase Xp in 
the inquiry hopping sequence that determines the frequency at which ID packets 
are transmitted is calculated as follows: 

Xp= [CLKNie-12 + koftset + {CLKNi_2,o - CLKNie-12) modl6]mod32 (1) 



This paper concentrates on Bluetooth's 79 hop system because it is applied in the 
vast majority of countries in the European Union and in the USA. In case of the 
reduced hop system, the inquiry hopping sequence contains only 16 frequencies. 



In equation 1, CLKN^-y^z denotes bits xtoy and bit z of the inquiring unit's 
native clock, ^offset G {24, 8} selects the active train yl or _B of the inquirer, ^offset 
is changed after a single train is repeated Ninquiry times. The frequencies within 
each train are shifted by one phase every 1.28 s, since after this time CLKNiq— 12 
changes. CLKN has a resolution of 312.5 /is. {CLKN4^2,o-CLKNie-i2) mod 16 
determines the phase within each train. The expression CLKNie-12 is necessary 
to avoid omitting a frequency when CLKNiQ-12 changes, since this could lead 
to a repetitive mismatch between inquiring and scanning unit. 
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Fig. 4. Overview of the inquiry procedure 



The device that agrees to bo rourul outers tiio Incjuiry Scl\n stato peri- 
odically. The time betwooii two coiisoculixo iii(|uiry scans is dotorniiiK^d l)y the 
inquiry scan interval Tinqscan- 'ili*^ inquiry scan window, 'Iwmq^ican^ spo(-ilios the 
time a unit stays in Inquiry Scan mode. During that time the unit listens at 
a single frequency in the inquiry hopping sequence for ID packets from the in- 
quirer. The current phase in the inquiry hopping sequence is determined by its 
native clock [5]: 

= CL/v Am^ - i^- (2) 

The Bluetooth standard dclincs 7;,„„^,.<„, > Ttrain = 10 m.s in order to 
ensure that a frequenc}' synchronization between inquiring and scanning unit 
takes place when the scanning frequency is in the currently active train of the 
inquirer. Also, the condition Tinqscan < 2.56 must hold. When the unit in In- 
quiry Scan mode receives an ID packet, it leaves the Inquiry Scan mode for 
a random backoff delay which is evenly distributed betw^een [0, . . . , 639.375] ms. 
This reduces the probability that units simultaneously transmit response pack- 
ets on the same frequency. AfterAvards. the unit enters Inquiry Response state 
and again listens for ID packets of the inquiring unit. When the unit in Inquiry 
Response state achieves frequency synchronization, it transmits a packet con- 
taining device information such as its current clock timing and its Bluetooth 
device address to the inquirer. 



4 Performance of Bluetooth's Inquiry Procedure 



A characteristic feature of ubiquitous computing settings is the presence of many 
highly autonomous, mobile cle\'ices with distinctive resource restrictions in a 
relatively small area. The aspects of scalability, energy consumption, and device 
detection delay are therefore crucial when evaluating Bluetooth's rendezvous 
protocols. 
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Fig. 5. Responses during inquiry subject to the number of devices in range considering 
different inquiry windows 




According to datasheets [14] and experimental measurements [12], the energy 
consumption in Inquiry and Inquiry Scan state is approximately twice as high 
as in normal receive and transmit modes. The Bluetooth standard suggests that 
devices could enter Inquiry mode for 10.24 s every minute. This means that 
Bluetooth devices would spend approximately 17% of their lifetime in Inquiry 
mode. Besides an unacceptably high energy consumption, this also leads to poor 
performance if many devices are present. Above all, in INQUIRY mode a Blue- 
tooth unit cannot actively exchange application data with other devices. Fig. 5 
shows the average number of responses during inquiry subject to the number of 
potential communication partners in range. It indicates that in the presence of 
only a Umited number of devices practically all units are found, when inquiry 
is chosen as suggested in the standard. It also indicates that performance dete- 
riorates as the number of devices grows, in that a smaller and smaller portion 
of devices are discovered. The reasons are manifold and are discussed in more 
detail in the following sections: 

— Because of a long random backoff delay. T^,inqscan must be very large when 
the scanning unit is supposed to ansAver more than once during one scan 
window. Large scan windows are undesirable because they are repeatedly 
blocking the device. 



— Since the relative clock differences of Bluetootfi units remain uncfianged, a 
unit tends to answer the same device in consecutive Inquiry Scan intervals 
(cf. equations 1 and 2). Fig. 5 shows that the overall number of responses 
is sufficiently high, but the same device often answers the same inquirer in 
consecutive inquiry scan intervals. This prevents the device from responding 
to other devices. Only in Inquiry Response state an offset is added to the 
scanning frequency after each response. However, multiple responses during 
a single inquiry scan window are only possible when the window is relatively 
large, which is undesirable in the envisioned application scenarios. 

— Large j^^"^"''"'' values lead to high numbers of overlapping inquiry windows 
where the devices cannot find each other. 

Regarding scalability and energy consumption the rendezvous layer must be 
designed to support inquiry parameter settings such that 

— the overall time a unit has to stay in Inquiry and Inquiry Scan modes is 
minimized, 

— the probability for overlapping Inquiry and Inquiry Scan states is maxi- 
mized, 

— the probability for overlapping Inquiry modes in different units is reduced, 
and 

— the time for the frequency synchronization delay between inquiring and in- 
quired device is as low as possible. 

Decreasing the value of 'jv^"^"''^'' leads to fewer overlapping inquiry inter- 
vals. Since Tinquiry Cannot be predetermined but generally depends on sensory 
input and application restrictions, one purpose of the rendezvous layer is to de- 
crease Tw inquiry, the inquiry window. Small inquiry values reduce the energy 
consumption and decrease the number of duplicate responses and overlapping in- 
quiry intervals. However, T„ inquiry cannot be decreased arbitrarily. Fig. 5 shows 
the average number of devices found during a 2.56 s compared to a 10.24 s in- 
quiry window subject to the number of devices in range. In 2.56 s the inquirer 
can probe only at a single train, which limits the number of responses. But com- 
pared to Twinquiry = 10.24 s, in the presence of many devices fewer duplicate 
responses are received, much less energy is consumed, and proportionally more 
devices are found. In settings with many devices, increasing T„ inquiry will not re- 
sult in the discovery of significantly more devices, because the devices will block 
each other. Even with large inquiry windows, in settings with many devices not 
all devices in range are found. 

5 Inquiry and Inquiry Scan Settings 

Device discovery in Bluetooth is performed in the Inquiry and Inquiry Scan 
procedures which are controlled by various parameters. These are shown in Fig. 3 
and Tab. 1. Tinquiry and Ti^qscan denote the interval between the start of two 
consecutive inquiries and inquiry scans, respectively. T^, inquiry and T^inqscan 



specify the duration of a single inquiry and inquiry scan, respectively. N^J^^^^^ 
depends on tlie memory restrictions of a device in that it restricts the number of 
inquiry responses that are processed. As pointed out before, Tinquiry depends on 
specific applications and sensory input. Therefore, the rendezvous layer does not 
influence Tinquiry and -/V^^f^es settings. The train repetition number Ninquiry 
defines the number of times a single train is repeated by the inquirer before a 
new train is used. 



Table 1. Inquiry and inquiry scan parameters 



Parameter 


Description 








Tu. inquiry 


inquiry window, Tu. inquiry < Tinquiry 




Tinqscan ' 


inquiry scan interval, Tinqscan < 2.56 


.[51 


T,^inqscan 


inquiry scan window, Ttrain = 10 ms^ 


< Tw inqscau < Tinqscan 




maximum number of responses proces 


sed in a single inquiry 




train repetition number, Ninquiry > 2 


56 (predefined, fixed) 



5.1 The Inquiry Scan Window 

A suitable value for the inquiry scan window is the minimal setting T„ inqscan = 
Ttrain = 10 ms^. Here, Ttrain IS the time period for the inquirer to send at 
all Ntrain = 16 frequencies in the active train. T^ inqscan should only be in- 
creased when Ninquiry IS noticeable smaller than 256 (which is not the case in 
Bluetooth), because the inquirer consecutively sends on more than Ntrain fre- 
quencies only when it switches between different trains. This happens just every 
Ttrain * Ninquiry seconds and would not justify the additional time a unit would 
have to spend in Inquiry Scan mode. 

In an error-free environment, T^ inqscan = Ttrain seems to be the best choice. 
However, in ubiquitous computing application scenarios where the probability of 
packet loss is relatively high, we suggest to choose T^ inqscan = '^*Ttrain = 20 ms 
to ensure that an inquirer can send ID packets at each frequency in its active 
train twice. If the ID packet that was sent at the scanning frequency gets lost, the 
inquirer can send it again at this frequency. Fig. 6 and 7 show the average number 
of devices found during inquiry considering inquiry scan windows of varying 
length in an error- free environment. Noticeably more devices are only found when 
Tw inqscan IS Substantially increased, because in this case the probability that a 
train switch takes place during scanning is significantly higher. However, since 
all connections have to be suspended during scanning, substantially increasing 
Tw inqscan IS uot recommeudable. Instead, as Fig. 6 and 7 suggest, decreasing the 



The definition of the WriteJnquiry_Scan_Activity HCI command says that 

T„ inqscan > 11.25 mS. 
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Fig. 6. Average number of devices found during inquiry subject to Tw inqscan and 
number of devices in range, Tinqscan = 2.56 s 



inquiry scan interval is much more effective regarding both energy consumption 
and the number of devices found. Increasing inqscan by a factor of 32 from 
10 ms to 320 ms is not as effective as lowering Tinqscan from 2.56 s to 1 s regarding 
the number of devices that are found during inquiry and the energy consumed. 

5.2 The Inquiry Scan Interval 

The inquiry scan interval, Tinqscan, denotes the time between the start of two 
consecutive inquiry scans. The condition Tinqscan < 2.5fi .s' must hold. Tinqscan 
is chosen such that the overall ciicrg\' coiisuiiiplioii of (Jio whole system of par- 
ticipating nodes is reduced. Coiisc(]uciill\'. the scan interval ctaii be shortened 
when in return the inquiry window of other devices can be reduced. Since ev- 
ery unit generally attains both inquiry and inquiry scan modes regularly, this 
is beneficial for the whole system of smart devices as well as for single units. A 
module in continuous Inquiry mode consumes significantly more energy than 
in periodic Inquiry Scan mode when the inquiry scan window is sufficiently 
small as suggested in section -5.1. 

Tinqscan cau be used to control the accessibility of single devices. A short 
inquiry scan interval entails that the device can easily be found by other devices. 
On the other hand, a low value of Tinqscan also means that the device might 
respond more often to the same device during consecutive inquiry windows. 

In order to decrease the time a unit has to stay in continuous Inquiry mode 
it is desirable that the first and second frequency synchronization before and 
after the random backoff delay (cf. Fig. 4) take place before a train switch in 
the inquiring unit occurs. Since a train switch takes place every Ttrain * ^inquiry 
seconds, a first approximation for a suitable Tinqscan is 

Tinqscan < Ttrain " N.nquiry " ^Anax " Ttrain (3) 

Here, RBmax = 639.375 ms is the maximum random backoff delay. For the 
standard settings and Ninquiry = 256 this results to Tinqscan < 1910.625 ms. 



Fig. 7. Average number of devices found during inquiry considering a different value 
for Tiuqscan (1.00 s) Compared to Fig. 6 (2.56 s) 



The above settings ensure that when there are only two devices and one 
of them enters Inquiry mode, the inquirer has to stay in inquiry mode for 
only 5.12 s (instead of 10.24 s) to find the other device with high probability. 
Especially in the presence of many devices it is worthwhile to decrease Tinqscan 
further. A lower value than 1910.625 ms leads to a higher energy consumption 
for scanning. But on the other hand, inquiry can be reduced to Ninquiry * 
Ttrain + Tinqscan + RBmax + Ttrain- Furthermore, a device with a short inquiry 
scan interval can respond to other devices more frequently. 

5.3 The Inquiry Window 

The inquiry window, Twinquuy flenotes the time a unit continuously stays in 
Inquiry mode. Since Inquiry is a mode with very high energy consumption, 
Tw inquiry should be as low as possible. In settings with a low number of Blue- 
tooth devices, a unit might prolong the inquiry window until no new devices are 
found for a certain amount of time. However, as shown before (of. section 4) in 
environments with a large number of devices, prolonged inquiry windows make 
the rendezvous layer inefficient because of overlapping inquiry windows, high 
energy consumption, and decreased accessibiUty of inquiring devices. Further- 
more, even in settings with large inquiry windows it cannot be assured that all 
potential communication partners are found. 

When equation .3 holds for all devices d € -D in communication range, a 
good lower bound for the inquiry window parameter would be T^^, inquiry = 
maxdg_D {( [ ^' y.'J' I'^^JT" J + 1) * Tinqscan{d)} + RB,nax. wliere D is the set of 
devices in range and Tinqscan{d) the inquiry scan interval of device d. This set- 
ting ensures that without overlapping inquiry windows and only a few devices in 
range all potential communication partners can be found with high probability. 

A generally appropriate setting for T^^ inquiry is T-u, inquiry = 2 * Ninquiry * 

Ttrain = 5.12 s, when Tinqscan and Tujinqscan are Selected as recommended in 
the previous sections. This enables the inquiring device to probe at frequencies 
in both trains for an equal amount of time and provides sufficient time to select 



responses. On the other hand the number of duphcate responses is relatively low 
and the energy consumption is much lower than for the suggested 10.24 s in the 
Bluetooth standard. 

However, T^inquiry = 5.12 s might be a suboptimal choice for environments 
with only few devices and is still very energy consuming. The next section deals 
with an adaptive protocol for Bluetooth-enabled smart devices that performs well 
independently of the number of devices present and further reduces inquiry to 
save energy. 



6 An adaptive rendezvous layer protocol for cooperative 

device discovery 

The performance of the standard Bhicloolli iiujiiiry procedure is sufficient for 
settings with a limited number of devices in communication range. But the per- 
formance decreases significanlly with a rising number of units. In such environ- 
ments only a fraction of the potential communication partners are found - even 
when Ta. inquiry IS high. Unfortunately, large values for T^, inquiry result in many 
duplicate responses, overlapping inquiry windows, and poor overall performance 
(cf. section 4). 

In settings with many devices, it is more appropriate to discover devices in 
a cooperative fashion. Cooperative device discovery splits up the task of finding 
communication partners between iiiulliplc units. One idea is to let only one 
or two units per piconet |5j haiuilc rciuiczvous tasks on behalf of the whole 
piconet; another is to utilize iiu]uir\' results of other devices that responded 
during inquiry. The goal of sucli measures is to reduce the overall number of 
devices that take part in inquiry and the overall time units have to stay in 
Inquiry mode in order to discover more devices in less time using less energy. 

In the adaptive protocol proposed here, a unit starts inquiry for a certain 
time window and accumulati^s responses from other devices. AKIiougli units 
do not know how many devices arc in range, they can estimate their number 
considering the number of devices tliat responded din'ing the first seconds of an 
inquiry. When, after a given time interA'al. more devices than a predetermined 
threshold were discovered, it concludes that many devices are in range, stops the 
inquiry, builds up connections to some of those devices, and gets further discovery 
information from them. By selecting devices with appropriate clock values, this 
can be done in such a way that a large subset of the available devices is covered, 
as explained below. 

The advantage of this approach is that it splits up the responsibility for 
inquiry between different nodes and, more importantly, that the time interval 
after which inquiry is canceled Avlien a stifficient nimiber of responses are ac- 
cumulated can be very short. In fact. Ave stiggest a value of only 2.56 s. Dur- 
ing this interval an inquirer onh' inqtiires at frequencies in a single train since 
Ttrain * ^inquiry > 2.56 s (cf. sectiou 3). That is, in the average case only 50% of 
devices in range can be found during the first phase of the protocol. However, the 



timing information transferred during inquiry responses enables the original in- 
quirer to identify devices that during their inquiries discover a subset of devices 
not found by direct inquiry. It might seem that connecting to another device 
consumes the energy saved by a shorter inquiry for the paging process - which is 
also very energy intensive. But since the timing information of this device were 
transferred during a recent inquiry response, connection establishment is almost 
instantaneous. The simulation results show that the overall execution time for 
the adaptive protocol is only slightly longer than the interval after which the 
actual inquiry is stopped. 

In the following, the algorithm for the inquirer is depicted. The inquiry 
scan settings in participating Bluetooth units should be chosen as described 
in section 5. The protocol can be implemented on top of Bluetooth 's Host Con- 
troller Interface (HCI) without changing lower layers of Bluetooth. An initial- 
ization for all Bluetooth-enabled smart devices should include enabling page 
and inquiry scans (HCI_Write_Scan_Enable) and setting the inquiry and page 
parameters (HCLWrite Jnquiry_Scan_Activity, HCI_Write_Page_Scan_Activity) . 
Furthermore, the page timeout should be chosen as low as possible in order to 
prevent a device from paging a unit that left its communication range for a long 
time (HCI_Write_Page_Timeout). After sending inquiry responses, units should 
enter PAGE ScAN state to ensure fast connection establishment. 

BRLP (Bluetooth Rendezvous Layer Protocol) 
Input: 

Inquiry settings for inquirer: Tinqnir, € \lZ'iun-y^'l^n^!^uiry\^ Tu-inyuiry, N^e^fce 
Time interval for normal inquir}-: HI\IJ'_l.iiiicoijt 
Threshold for device responses: Bl{Ll'_sizc 

Number of devices to retrieve discovery information from: Ngeiect 
Output: 

Bluetooth device addresses and clock settings of devices 

ensUre(T™^^j^j^ > inquiry) 

inqtimer = random(T,?^*^i^y, TV^qZiry) 
do forever 

if time.over (inqtimer) then 
responses, delete 0 

HCIJnquiry(ALL_DEVICES, Tu,inquiry, N^vfces) 
inqtimer = Tandom{Tr^^,^y, TV^^^i^y) 
BRLP_timer = BRLP.timeout 
end if 
end do 

inquiry _response_event_handler(Inquiry_Response_E vent e) 
begin 

response = e.getResponse() 
r esp onses . add (response) 

if not time_over(BRLP .timer) and responses. size > BRLP^size then 



HCLInquiry_Cancel() 

selected_responses = responses. select(A^seiect) 
for all sr in selected-responses do 

HCI_Create_Connection(sr) ^ 
end for 
end if 

end 

connection_complete_event_handler(Connection_Complete_Event e) 
begin 

get _assembled_devices (e . connectionJiandle) ; 
end 



The suggested protocol decreases the level of confidence in the obtained re- 
sults, because they are partially retrieved indirectly from other devices and might 
refer to units outside the communication range. This is not a severe problem, 
however, because direct results might also be inaccurate - e.g. obsolete because 
of mobility - and the algorithm has to deal with uncertain results anyway. Sec- 
tion 7 shows how sensory input can be used to decrease this uncertainty. Also, 
in order to inhibit error propagation, a unit is only allowed to pass on discovery 
information that it learned from its own most recent inquiry procedure. A low 
value for BRLP_size means that only a few inquiry results are available to be 
transferred to other devices. This entails that this parameter should be adapted 
after each inquiry process. A variation of the described protocol is to carry out 
normal inquiry for a certain amount of time (for example 2.56 s) regardless of 
the number of devices found during this inquiry window. When more than a 
given threshold of units have been found after this period, connections to some 
of these devices are established and discovery information is requested. 

To clarify the performance of the adaptive part of the algorithm. Fig. 8 
shows the average number of devices found considering a very low value for 
BRLP_size. It considers only the cases in which after 2.56 s inquiry connections 
to other devices are established to request discovery information. From the set of 
inquiry results two devices are selected to retrieve further discovery information 
from {N selected = 2). The selection criteria are explained below. The average 
total time for the initial 2.56 s inquiry, connection estabUshment, and transfer 
of discovery information from the two selected devices was 3.44 s. Compared 
to normal inquiry with T^inquiry = 10.24 s a better performance regarding the 
number of responses is achieved, and the time a unit has to stay in inquiry mode 
is reduced significantly. Therefore, the adaptive protocol results in substantial 
energy savings, enables units to enter energy-saving modes more frequently, and 
leaves more time for application specific tasks. 

The selection of units to retrieve discovery information from is important for 
the performance of the adaptive algorithm. The retrieved discovery information 



^ See the definition of HCI_Create_Connection for the exact sequence of parameters. 
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s accumulated with the adaptive protocol 



is only useful if it contains inquiry results from devices not already found by 
direct inquiry. The probability for this is highest, when devices with appropriate 
clock offsets are selected. The clock offsets are part of the inquiry results. 




Fig. 9. Phases covered by different units relative to CLKNiq_i2 during inquiry i 
train A 



When the timeout for the initial inquiry, BRLP_timeout, is lower than or 
equal to Tt^ain * N inquiry = 2.56 .s - which is desirable regarding energy con- 
sumption - only the frequencies of a single train are inquired. Let / be the in- 
quiring and S a scanning unit that responded to / during the initial inquiry 
window. CLKNle_^^ and CLKN^q_^^ shall be bits 12 to 16 of the native 
clock of / and S, respectively. The frequencies at which / inquires and S scans 
only depend on CLKNIq_-^2 ™d CLKN^q_-^2 (cf- equations 1 and 2). Let the 
first active train during inquiry be train A. Then, the phases of the frequen- 



cies in the active train are [CLKNli_^^ - 8, . . .,CLKN(q_^2 + 7] (mod 32). 
When CLKNfe_^2 e [CL/iW/g^ia - 8, ■ ■ ■ ,CLKN(e_^^ + 7] during one in- 
quiry scan interval this will also be the case during all successive inquiry scan 
intervals due to constant clock differences. This is important: because of given 
constant clock differences it does not matter when a device enters inquiry state. 
It will always find the same devices scanning at frequencies in the same train, 
because the frequencies in a train also depend on CLKNi6-i2- This implies 
that / should select a device S to obtain discovery information from, such that 
\CLKN(g_y2 - CLKNfQ_y2\ is maximal. 

Fig. 9 illustrates this in the light of a concrete example. The semicircles show 
the frequency phases covered by units /, 5*1, and S2 during inquiry in train A 
relative to CLKNIq_i2- The inquiry of / results in the discovery of two units, 

and S2. The clock offset of 5i is CLKNfi_-^2 - CLKNIq_-^2 = -8; that of 
5^2 is CLKN^Q_-^2 ~ CLKNIq_i2 = 7. These relative clock differences remain 
constant over a longer period of time, although the CLKNie-12 change every 
1.28 s, possibly at different times, rotating the halfcircles right. Fig. 9 shows that 
Si and 5^2 in their inquiries cover frequency phases relative to CLKN(q_i2 that 
are not traversed by /. Units scanning at these phases with a relative distance 
greater than 7 or less than —8 are never found by /, regardless of the current 
value of CLKNie-12- Since the clock offsets of Si and 5^2 are maximal, they 
cover the maximal number of phases relative to CLKNIq_i2 not traversed by 
/. By transitively selecting devices from the discovery information of Si and 5^2 
it is possible for / to choose devices that have optimal clock offsets in order to 
cover a large area of phases. In the same way that a device Sgpt is an optimal 
choice for /, / vice versa is an optimal choice for Sgpt - the relationship is 
symmetric. Therefore in a setting with a large number of devices present, a few 
devices can form stable subgroups to cooperatively perform device discovery. 
They complement each other, and the whole system as well as individual units 
profit in terms of energy savings, number of devices discovered, and shorter 
discovery delays. 



7 Using sensory input to improve rendezvous-layer 
protocol performance 

When everyday items are augmented with information processing capabiUties 
they will provide information about their environment to other devices, thus 
enabling collaborative perception of the environment. In the Smart-Its project, 
smart devices are equipped with a wide variety of different sensors for physical 
parameters like temperature, acceleration, pressure, etc. An interesting question 
is how sensory data that is accumulated independently from the communication 
platform can be used to improve rendezvous layer protocol performance. The 
idea to take advantage of context information - especially location - in commu- 
nication protocols has already been applied to other protocol layers, e.g. routing 
protocols [8]. 



7.1 Context for Adapting Inquiry Parameters 

If sensory input from acceleration or general location sensors are available, the 
inquiry parameter settings can be adapted when a device moves. Since it is more 
probable that a moving device enters a new environment, the inquiry window is 
prolonged or the inquiry interval is shortened in order to discover these devices 
more quickly. In this case only individual devices increase their inquiry window; 
this does not lead to a deterioration of the rendezvous layer protocol performance 
of the system as a whole. Alternatively, the inquiry scan interval is reduced to 
ensure that other units can access the device faster. In general, aU sensory input 
that hints at an increased usage of the device in the future could result in such 
an adjustment of inquiry parameter settings. 

Context information can also be used to implement the select routine in the 
adaptive rendezvous layer protocol. The purpose of the select statement is to 
choose such devices among all units that responded during inquiry, for which 
the uncertainty of transferring obsolete device information is lowest. When no 
sensory input is available, devices are selected as shown in the previous section 
or randomly from the set of devices that already responded during inquiry. But 
when context information is available, then it should be used to select devices 
that are as near as possible, that inquired at different frequencies, and that 
started inquiry most recently. In the Bluetooth 1.1 standard there exists a link 
manager protocol (LMP) command to determine the signal strength to other 
Bluetooth devices. This information could be used to evaluate whether the device 
is suitable to get inquiry information from. 

7.2 Restricting Device Discovery to Symbolic Locations Smart 
Doors 

One of the main differences between l\'picaL pervasive computing settings and 
traditional distributed systems is that luau}' smart devices such as the Bluetooth- 
enabled Smart-Its do not possess comentional input and output capabiUties 
such as buttons, keyboards, or screens. Instead, sensors attached to smart de- 
vices, perceived sensory input, and context information derived collaboratively 
among different objects determine whether, when, and how entities are going to 
communicate with each other. 

Based on the Bluetooth-enabled Smart-Its (cf Fig. 1) we have built several 
context-aware applications in which history information as well as the context 
of devices and users determine whether tAvo entities are going to exchange in- 
formation with each other [19]. A critical propc^rly of these applications is that 
communication is often restricted to a (-(^rlaiii s\iiiboIic location shared by sev- 
eral smart objects. For example, smart objects in a certain room often only 
need to communicate with other Bluetooth-enabled mobile devices that share 
the same symbolic location. As radio waves penetrate walls, the conventional 
Bluetooth inquiry procedure is not suitable to distinguish between devices in 
different rooms. Furthermore, as shown in the previous sections, especially in 



the presence of many devices, the Bluetooth inquiry procedure can become too 
slow for ad hoc interaction. 

Therefore, we have developed the concept of smart doors that (1) determine 
whether two Bluetooth-enabled devices share a certain symbolic location and (2) 
considerably reduce the time in which new devices are found. Smart doors are 
appliances that improve the rendezvous layer protocol performance of Bluetooth- 
enabled smart devices by using passive RFID technology. Passive RFID labels 
are attached to users' mobile devices such as mobile phones and PDAs. RFID 
tags contain the access parameters of devices, i.e. information about how these 
devices can be reached. For example, an RFID tag attached to a Bluetooth- 
enabled mobile phone contains the phone's Bluetooth device address and the its 
phone number. An RFID reader attached to a Smart-Its, which is mounted to the 
entrance of an office (cf. Fig. 10) serves as the main sensor. When a user enters a 
room, the RFID tag attached to the mobile device is scanned by the RFID reader 
and the corresponding RFID data is processed by a Smart-Its. Smart objects 
know to what room they belong because the Smart-Its at the door connects 
to devices entering the room and transmits the current location information. 
Devices in the room have typical pull and push options: they can connect to 
the smart door each time they are interested in devices sharing their symbolic 
location. Alternatively, they can be notified by the smart door whenever a new 
device enters a room. The latter alternative is very efficient when subscribed 
devices belong to the piconet of the smart door as the information can then be 
transferred via Bluetooth piconet broadcast. 




Fig. 10. Smart doors are equipped with an RFID reader and antenna (1) as well as 
a Bluetooth-enabled Smart-Its [18| (2). The RFID tags attached to Bluetooth-enabled 
mobile phones (3) are read out each time a users enters a room, and the RFID in- 
formation is transmitted via Bluetooth broadcast to other smart devices in the room. 



The main advantages of the smart door approach are that it (1) reduces the 
amount of interference by restricting communication to devices sharing the same 
symbolic location and (2) minimizes the time mobile, battery-powered devices 
have to perform the energy- consuming task of conventional Bluetooth inquiries. 

8 Conclusion 

The standard inquiry procedure of Bluetooth consumes much energy which is 
problematic for communicating smart devices in ubiquitous computing settings. 
This paper showed how the standard inquiry parameters can be adapted to 
decrease power consumption and increase the scalability of the inquiry proce- 
dure. Since typically smart devices perceive their environment through sensors, 
we also presented ways for using sensory input to improve the performance of 
Bluetooth's rendezvous layer. 

Furthermore, it was pointed out that the scalability of Bluetooth 's inquiry 
procedure is not sufficient if many devices are present. As a result from this ob- 
servation, an adaptive protocol for cooperative device detection was introduced 
that reduces energy consumption and improves scalability for environments with 
many devices. 

The properties of Bluetooth's rendezvous layer that have the strongest impact 
on device detection delay are a relatively high random backoff delay and the 
existence of two separate frequency trains. In terms of the rendezvous layer for 
general frequency hopping systems there should be only a single train comprising 
all 32 frequencies of the inquiry hopping sequence. Alternatively, Ninquiry could 
be reduced to one, and the minimum inquiry scan window should be increased to 
20 ms. It is important to note that even with these adaptations the majority of 
parameter selection rules and the adaptive rendezvous layer protocol presented 
in this paper are stiU applicable. 
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